Enhanced certificate authority

ABSTRACT

An enhanced certificate authority system and method allows for the enhanced security, validation and Multi-Factor Authentication of user&#39;s within a digital signature and transaction system through the creation and management of a user&#39;s Digital Identity certificate so that through an enhanced certificate authority a user&#39;s identity and bona fides may be both protected and established across a diversity of electronic devices and transactions.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 14/918,865 titled “Enhanced Certificate Authority”, filed onOct. 21, 2015, the disclosure of which is herein incorporated byreference in its entirety.

PATENTS CITED

The following documents and references are incorporated by reference intheir entirety Ibraimi et al (U.S. Pat. Appl. No. 2013/0073860), Saxenaet al (U.S. Pat. Appl. No. 2012/0159172), Hsien (U.S. Pat. Appl. No.2013/0145166), Huotari et al (U.S. Pat. No. 7,813,717), Candelore et al(U.S. Pat. Appl. No. 2011/0055577), Wheeler et al (U.S. Pat. Appl. No.2004/0128508), Ramalingam et al (U.S. Pat. No. 8,341,029), Chamberlain(U.S. Pat. No. 8,417,958), Varga (U.S. Pat. No. 8,332,322), Brandt et al(U.S. Pat. Appl. No. 2013/0159723), Labaton (WO 99/22362) and Jarvie etal (U.S. Pat. No. 8,473,735).

FIELD OF THE INVENTION

The present invention relates to a system for creating and managing auser's Digital Identity certificate so that through an enhancedcertificate authority a user's identity and bona fides may be bothprotected and established across a diversity of electronic devices andtransactions.

DESCRIPTION OF THE RELATED ART

The proliferation of electronic forms of identification andtransactions, coupled with the increased needs of privacy andauthentication, makes for an ever increasing necessity forauthentication tools that provide users with the ability to digitallysign and authenticate transactions and documents with their electronicauthority via some form of digital signature or electronic postmark.Such methods have been traditionally used to authenticate the identityof the sender of a particular message or to authenticate the time/dateat which the message was created.

Increasingly, however, it is not only important to establish theidentity and time/date of creation of an electronic item, but alsocritical to update it as time goes along. Looking at the emission ofDigital Certificates (CERT), a particular problem resides in therelatively long duration of their validity (often one to two years),time during which many things about a user may change (Last names,address, valid licensatures, etc.). Simply making CERT last less timewould overload the present validation processes.

What is required, is a system and method through which a long lastingvalidation certification may be accomplished initially, but where CERTsfor open market digital signatures are issued for a short period of timebased on a one or few transactions whose data is optionally validatedand Multi-Factor Authenticated at the time of issuance of saidTransaction Certificate.

SUMMARY OF THE INVENTION

This section is for the purpose of summarizing some aspects of thepresent invention and to briefly introduce some preferred embodiments.Simplifications or omissions may be made to avoid obscuring the purposeof the section. Such simplifications or omissions are not intended tolimit the scope of the present invention.

In one aspect the invention is about a computerized system for managingdigital certificates, said computerized system comprising one or morecommunicatively coupled processors, said one or more processors forminga Certificate authority computer system (CACS) configured to perform thesteps of: receiving, at said computer system, a request for a Proxydigital certificate (PCERT) from a user desiring said authorized PCERTfrom said Certificate Authority, said request containing one or moreproxy request data elements, sad proxy request data elements comprisingthe actual data for each user related data field and/or a pointer to thelocation of said data, said user data information being required by thecomputer system to accomplish (directly or via third parties) the one ormore registration validation actions necessary to establish the bonafides of said user and perform said user registration within the system;providing, upon said bona fides satisfaction, said user with said(PCERT), any suitable PCERT ancillary data and one or more PCERT dataelements associated with said one or more proxy request data elements;receiving, by said CA computer system, a request for a TransactionalDigital Certificate (TCERT) from a user, said request containing thedesired one or more TCERT user data elements and establishing theexistence of a valid PCERT, performing certificate validation of one ormore of said TCERT request data elements, said PCERT data elementsand/or said PCERT, and upon acceptance generating said TCERT digitalcertificate and any suitable TCERT ancillary data for said user;Transmitting, by said CA computer system, said TCERT digital certificateand any appropriate TCERT ancillary data to said user.

In another aspect, said TCERT request data elements are comprised of oneor more of the following possible TCERT data elements to be included insaid TCERT; actual user data and/or a pointer to the location of saiduser data and/or user data field names and/or tokenized values and/orvisual references to data; and if a portable PCERT and/or TCERT isdesired, said PCERT ancillary data and/or said TCERT ancillary data maycontain a CA generated PrK/PubK key pair to be communicated to saiduser. In yet another aspect, said request for a certificate validationof said TCERT request data elements and said PCERT include establishingthe validity of each said TCERT data element at the time of said TCERTrequest; and said certificate validation of said TCERT includes saidrequest being digitally signed by said user using said PCERT. In anotheraspect, said certificate validation of said TCERT request data elementsand said PCERT include in addition the real-time multi-factorauthentication (MFA) of said user, wherein said MFA includes at leastone of the following user interactions: telephonic, password, biometric,token (H/W and/or S/W), Password, Pincode, One Time Password, Biometrics(including Face, Finger, Iris, Veins, Voice and others), Machinegenerated unique codes, Machine Digital Signature, Machine DigitalSignature on a secured cryptographic device token and/or Machinegenerated Unique Code on Secure Cryptographic Device token, LDAP, otherauthentication and/or authorization servers.

In one aspect, the invention is about a computerized system for managingdigital certificates, said computerized system comprising: one or morecommunicatively coupled processors, said one or more processors forminga Certificate authority computer system (CACS) configured to perform thesteps of: receiving, at said computer system, a request for a Proxydigital certificate (PCERT) from a user desiring said authorized PCERTfrom said Certificate Authority, said request containing one or moreproxy request data elements, sad proxy request data elements comprisingthe actual data for each user related data field and/or a pointer to thelocation of said data, said user data information being required by thecomputer system to accomplish (directly or via third parties) the one ormore registration validation actions necessary to establish the bonafides of said user and perform said user registration within the system;providing, upon said bona fides satisfaction, said user with said(PCERT), any suitable PCERT ancillary data and one or more PCERT dataelements associated with said one or more proxy request data elements;receiving, by said CA computer system, a request for a TransactionalDigital Certificate (TCERT) from a user, a PCERT, but wherein saidrequest TCERT request data elements are comprised of one or more of thefollowing possible TCERT data elements: a pointer to the location ofsaid user data and/or user data field names and/or tokenized valuesand/or visual references to data; performing certificate validation ofone or more of said TCERT request data elements, said PCERT dataelements and/or said PCERT, and upon acceptance transmitting to saiduser the values of the data fields included in said TCERT request;transmitting, to said CA a digitally signed request including said CAprovided data values, said user PubK and digitally signed by the User;receiving, said data from said user, and generating a TCERT using saidinformation; transmitting, by said CA computer system, said TCERTdigital certificate and any appropriate TCERT ancillary data to saiduser.

In one aspect, the invention is about a method of managing digitalcertificates, by a computer system, said method comprising the steps of;providing one or more communicatively coupled processors, said one ormore processors forming a Certificate authority computer system (CACS);receiving, at said computer system, a request for a Proxy digitalcertificate (PCERT) from a user desiring said authorized PCERT from saidCertificate Authority, said request containing one or more proxy requestdata elements, sad proxy request data elements comprising the actualdata for each user related data field and/or a pointer to the locationof said data, said user data information being required by the computersystem to accomplish (directly or via third parties) the one or moreregistration validation actions necessary to establish the bona fides ofsaid user and perform said user registration within the system;providing, upon said bona fides satisfaction, said user with said(PCERT), any suitable PCERT ancillary data and one or more PCERT dataelements associated with said one or more proxy request data elements;receiving, by said CA computer system, a request for a TransactionalDigital Certificate (TCERT) from a user, said request containing thedesired one or more TCERT user data elements and establishing theexistence of a valid PCERT, performing certificate validation of one ormore of said TCERT request data elements, said PCERT data elementsand/or said PCERT, and upon acceptance generating said TCERT digitalcertificate and any suitable TCERT ancillary data for said user;transmitting, by said CA computer system, said TCERT digital certificateand any appropriate TCERT ancillary data to said user.

Other features and advantages of the present invention will becomeapparent upon examining the following detailed description of anembodiment thereof, taken in conjunction with the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows some of the Challenges found by this type of systems,according to an embodiment of the invention.

FIG. 2 shows an illustration of the various potential users of thesystem and method, according to an exemplary embodiment of theinvention.

FIG. 3 shows an illustration of a typical user enrollment, according toan exemplary embodiment of the invention.

FIG. 4 shows an illustration of the typical Security Diamond, accordingto an exemplary embodiment of the invention.

FIG. 5 shows an example DLF transaction, according to an exemplaryembodiment of the invention.

FIGS. 6A-6B show overviews of the Digital Life Framework components,according to exemplary embodiments of the invention.

FIG. 7 shows components of a DLF transaction, according to an exemplaryembodiment of the invention.

FIGS. 8-9 show examples of a transaction for a typical DLF user,according to exemplary embodiments of the invention.

FIGS. 10-11 show examples of Geolocation PAC units, according toexemplary embodiments of the invention.

FIG. 12 shows components of a DLF transaction related to tickets for aconcert, according to an exemplary embodiment of the invention.

FIG. 13 shows the computing components of a DLF, according to anexemplary embodiment of the invention.

FIG. 14 shows details of the computing components of a DLF back-end,according to an exemplary embodiment of the invention.

FIG. 15 shows details of the computing components interacting in thecase of a user and the government, according to an exemplary embodimentof the invention.

FIG. 16 shows the servers and their interactions in a DLF, according toan exemplary embodiment of the invention.

FIG. 17 shows details of the third party (3^(rd)) interaction for theBrokers and the DLF, according to an exemplary embodiment of theinvention.

FIG. 18 shows the basic credentialing process, which may changedepending on protocols, according to an exemplary embodiment of theinvention.

FIG. 19 shows ID Management and ID Broker components, according to anexemplary embodiment of the invention.

FIG. 20 shows further ID Management and ID Broker components, accordingto an exemplary embodiment of the invention.

FIG. 21 shows further ID Management and ID Broker components, accordingto an exemplary embodiment of the invention.

FIG. 22 shows Information (ID) Broker components, according to anexemplary embodiment of the invention.

FIG. 23 shows Information (ID) Broker components, according to anexemplary embodiment of the invention.

FIG. 24 shows Digital Life Framework Components, according to anexemplary embodiment of the invention.

FIG. 25 shows Government and Private Information Brokers, according toan exemplary embodiment of the invention.

FIG. 26 shows a third party integration with the use of ID Brokerexample, according to an exemplary embodiment of the invention.

FIG. 27 Actual front end applications and products for a monetizationstrategy, according to an exemplary embodiment of the invention.

FIG. 28 shows an exemplary Information Broker vis-à-vis ID Brokerinteraction, according to an exemplary embodiment of the invention.

FIG. 29 shows an exemplary digitally signed transaction using today'sdigital certificate and a user's PrK/PubK keys, according to anexemplary embodiment of the invention.

FIG. 30 shows the typical process for generating a CERT, using today'smethod and technologies, according to an exemplary embodiment of theinvention.

FIG. 31 shows a proposed alternate process for generating a PCERT,according to an exemplary embodiment of the invention.

FIG. 32 shows a proposed alternate process for generating a portablePCERT, according to an exemplary embodiment of the invention.

FIG. 33 shows a proposed alternate process for generating a TCERT basedon a PCERT, according to an exemplary embodiment of the invention.

FIG. 34 shows a proposed alternate process for generating a portableTCERT, according to an exemplary embodiment of the invention.

FIGS. 35-36 shows alternate proposed processes for generating a TCERT,according to an exemplary embodiment of the invention.

The above-described and other features will be appreciated andunderstood by those skilled in the art from the following detaileddescription, drawings, and appended claims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

To provide an overall understanding of the invention, certainillustrative embodiments and examples will now be described. However, itwill be understood by one of ordinary skill in the art that the same orequivalent functions and sequences may be accomplished by differentembodiments that are also intended to be encompassed within the spiritand scope of the disclosure. The compositions, apparatuses, systemsand/or methods described herein may be adapted and modified as isappropriate for the application being addressed and that those describedherein may be employed in other suitable applications, and that suchother additions and modifications will not depart from the scope hereof.

Simplifications or omissions may be made to avoid obscuring the purposeof the section. Such simplifications or omissions are not intended tolimit the scope of the present invention. All references, including anypatents or patent applications cited in this specification are herebyincorporated by reference. No admission is made that any referenceconstitutes prior art. The discussion of the references states whattheir authors assert, and the applicants reserve the right to challengethe accuracy and pertinence of the cited documents. It will be clearlyunderstood that, although a number of prior art publications arereferred to herein, this reference does not constitute an admission thatany of these documents form part of the common general knowledge in theart.

As used in the specification and claims, the singular forms “a”, “an”and “the” include plural references unless the context clearly dictatesotherwise. For example, the term “a transaction” may include a pluralityof transaction unless the context clearly dictates otherwise. As used inthe specification and claims, singular names or types referenced includevariations within the family of said name unless the context clearlydictates otherwise.

Certain terminology is used in the following description for convenienceonly and is not limiting. The words “lower,” “upper,” “bottom,” “top,”“front,” “back,” “left,” “right” and “sides” designate directions in thedrawings to which reference is made, but are not limiting with respectto the orientation in which the modules or any assembly of them may beused.

It is acknowledged that the term ‘comprise’ may, under varyingjurisdictions, be attributed with either an exclusive or an inclusivemeaning. For the purpose of this specification, and unless otherwisenoted, the term ‘comprise’ shall have an inclusive meaning—i.e. that itwill be taken to mean an inclusion of not only the listed components itdirectly references, but also other non-specified components orelements. This rationale will also be used when the term ‘comprised’ or‘comprising’ is used in relation to one or more steps in a method orprocess.

As the physical and virtual worlds merge, humans increasingly find thenecessity to track multiple identities (multiple emails, Social Mediapersonalities and avatars, etc.). The increasingly complex world ofNational and International privacy regulations contributes byeffectively forcing humans not only to keep multiple password lists, butan ever increasing complicated web of permissions, certificates, etc.

Referring to FIG. 1, we see some of the typical challenges. Theseinclude challenges 102 related to actual accounts (e.g. Identity andCredential challenges, Transactions, Scalability, etc.), challengesdriven by Social perception 104 and those driven by 3rd partyintegration 106, in an effort to control ID Theft 108 and Fraud 110. Ineffect, we need a Digital Life Framework (DLF) to manage the variousportions of this digital life. In effect, the DLF is a human interactionand transaction system and method, which shows and implements a numberof approaches to ensure the secure handling of digital signatures aswell as the interaction of personal data with the establishment ofappropriate transaction security.

There is a need to make available access to personal/corporateinformation to all users on the internet (be it fixed and/or mobileplatforms) via access to multiple personal and corporate platforms(including all government, corporate, personal and other services) in aform where the users (be they citizens or corporations) will need toprovide basic information only once and in an integrated manner. In thisfashion, we could broaden the efforts to place the largest possibleamount of government and/or corporate forms online, reducing handlingcost and human error.

Such a system would empower Corporations as well as the Federal, State,County or City government entities to provide a true one stop shop whereall citizen information is available and where consumers may go checkwhat information about them is available as may control/modify it. Inone embodiment, we can imagine a user removing any mental diagnosis fromthe approved HIPAA data fields, unless the agency requesting it iscleared to obtain such information.

The challenges of doing the above include providing solutions toIdentity and Credential management lifecycle, Transaction analysis andauthorization enforcement, Interoperability with multiple platforms,Scalability and availability, Data Integrity, confidentiality,Regulatory compliance at multiple levels, Agencies internal issues atmultiple levels, among others.

Of course the above is complicated through Social Perception, Usabilityand effectiveness, “Big Brother” watching syndrome and various privacyregulations and laws. Add to it the various Third Parties concerns (e.g.Integration, Compliance, Liabilities), and we see the importance of aconscientious solution.

Any proposed cost effective solution needs to also avoid potential sideeffects (e.g. unauthorized access by unrelated parties). Such issueshave been demonstrated in events like that of May 30, 2011: “Hackers usestolen RSA information to hack Lockheed Martin” (www.dailytech.com), andOct. 9, 2012: “The South Carolina Department of Revenue today announcedthat approximately 3.6 million Social Security numbers and 387,000credit and debit card numbers have been exposed in a cyber attack . . .” (www.sctax.org/newsreleases/). An optimal solution does not rely onany one technology, but incorporates several components.

The proposed solution is an integrated secure logical and physicalaccess with multi-factor authentication, including Role based,Biometrics, Smart Cards and/or Tokens. The Secure document managementwould include both Document integrity and confidentiality as well asIntegration with third party Document Management Systems.

In one embodiment, such a complete identity and credential managementsystem (a Digital Life Framework or DLF) would be used. In addition to afull Application Programming Interface (API) for integration withauthorized third parties, as well as Credential for secure system access(e.g. Employees, Citizens, Authorized third parties, etc.), such asystem could utilize existing PAC's infrastructure so that transactionanalysis with secure enforceability would be accomplished. The abovewould include a full Public Key Infrastructure (PKI) lifecycle (as wellas other types and methodologies of digital signatures), includingdigital signatures for both users and devices. In addition, regulatorycompliance would include complying with laws such as Privacy Act, HIPAA,FISMA, FERPA, Webtrust & others.

Digital signatures (DS) have become an important part of e-commerce. Theorigination of a digital signature generally includes: (1) thecalculation of a message digest—such as a hash value; and (2) thesubsequent encryption of the message digest. The message digest isdigitally signed by an electronic device using a private key (PrK) of akey pair used in public-private key cryptography (also known asasymmetric cryptography). The resulting ciphertext itself usuallyconstitutes the digital signature, which typically is appended to themessage to form part of the Electronic communication (EC).

The second part of originating the DS—using encryption with a privatekey—is referred to herein as “generating” the digital signature, and thecombined two steps is referred to herein as “originating” the digitalsignature. Furthermore, while the generation of the digital signature isconventionally understood as the encryption of the message digest, it iscontemplated herein that generating the digital signature also mayinclude simply encrypting the message rather than the message digest.Digital signatures are important because any change whatsoever to themessage in an EC is detectable from an analysis of the message and thedigital signature. In one well known embodiment, decryption of themessage is accomplished by using the public key (PubK), as is wellknown.

Accomplishing the above security would also include InformationAssurance lifecycle including incident management, Custom encryption Keymanagement as well as Symmetric and Asymmetric encryption implementationincluding Hardware Security Modules. As we see in FIG. 2, in oneembodiment a user 202 (be they at home, office, or on the road) orentity 204 would use the external application programming interface orAPIs 206 (whether mobile or not), from their computer desktop, mobileplatform, tablet, laptop, cell phone to interact with the governmentportal 208 (in this case pr.gov), where the system backbone 210 wouldproceed to establish the user's bona-fides, provide digitalcertification and verification under secure telecommunication conditions(through the appropriate servers/access points), regulatory compliance,integration and security while interacting with the government's orother third party service suppliers (including other governmententities).

In some cases, the user would then interact with a human at acorporation or agency #1 212, where there may be an additional civilian,in others with a human or server at corporation or agency #2 214, inboth cases through an internal API established within the governmentalagency. Through the management of the SecurelD management, signaturedevice and/or procedures, as well as the provenance and traceability ofeach interaction, the user and the government/corporate entity would beguaranteed that the various participants were who they claimed to be.

The above (FIG. 3) is guaranteed because the data management 300 is atall times (Enrollment Solution 302, Personalization Solution 304,Delivery Solution 306 and Post Issuance Solution 308) utilizing SecurelDmanagement techniques capable of establishing their bona fides withoutthe possibility of unauthorized duplication or mis-appropriation.

The above concepts are based FIG. 4 on an augmented Security Diamond(SD) 400. That is, a SD that is augmented by the geolocation of thedigital signatures generated by the system. Recall the SD is a conceptwherein to establish someone's identity and bonafides, we must know“What they know” 402, “What they Have” 404, “Where they are”406 and “Whothey are” 408, in a firm and non-doubtable way. The above information isnot only require to establish the Bonafides of the users 202, but alsoof the others (persons as well as entities) attempting to establish thebonafides of others. In contrast to many other solutions, in oneembodiment the SD used by the proposed solution, is capable ofestablishing the geolocation of various 3rd parties by distinct piecesof H/W and/or S/W.

By establishing these bonafides about all participants, FIG. 5, whensomeone 510 (say a potential employer) is trying to access informationabout someone, in crossing a firewall or barrier 502 we utilize all orparts of a digital signature to access information about a user's 202actual information (about themselves 504), about their work environment506 (in this case their diploma or transcript) and/or their purchasesand/or payments 508. This framework is in the digital space, hence theDLF concept.

Today, because of legacy systems, we often need to print a physicalrepresentation for legacy legality of transactions. However, as theworld converts to one of digital media, and more and more of our lifebecomes digital, the need to sign and approve those same transactionsneed to occur in a digital form, yet maintain the same proof andintegrity as our physical life. In essence, your DLFcontains/tracks/signs/verifies the levels of digital information youshare, based on the DLF operating across various applications. A DLFcreates an information vault that controls what information is shared,based on the level of trust. In effect, the Digital Life Framework actsas a personal safety vault where we keep the things that belong to us,in the digital world. These things include information about you, yourfamily/friends/life and the other extensions of your life. In oneembodiment, these include any and all things related to you.

In effect, the framework can then use an Identity Broker or ID managersto manage Digital Signatures (DS) [both yours and of other partiestrying to interface with your DLF], and manage interactions aboutindividual information items related to you. The ID Broker is an IDManager that controls under which conditions you provide access to yourinformation to others. These limits may include ‘expiration dates’(beyond which you stop sharing information elements with someone), aswell as other conditions.

Imagine FIG. 6A, the ID vault (or ID Broker) 602 interfacing with otherapps 604 (such as those developed by other parties), other webpages 606,or larger ‘pseudo O/S’ applications (such as Facebook 606 and/orLinkedIn 608). These two latter ones are separated, as they are ineffect apps within apps.

In a data sense FIG. 6B, a DLF 600 is comprised in one embodiment of anID Broker (IDB) 602 which interfaces with one or moreapplications/entities with relations to one or more data aspects of aperson's digital life. The IDB 602 is who decides with whom to sharewhat information. This information may include one or a combination ofvarious aspects, including; Legal 644, Education 646, Payment 648,specific transactions such as Ticketing 610, Business 612 (includingareas specific to your work 624 or your own business 626), Health 614,permanent health records 616 (such as Electronic Medical Records),Lifestyle 618, including weight information 620, as well as Gymattendance 622, insurance 628.

In short, the areas above would represent information specific you, forwhich access would only be granted when the appropriate bonafides of theaccessing agent are established, based on the SD. Imagine for example apotential employers wanting to confirm your academic credentials. Thatentity would first be validated in checking their DS via your own or athird party (say the CA DS Engine 640, a transaction authorizationtables (TAT) and/or the transaction authorization path (TAP)), which theIDB 602 will accomplish by tasking the ID Signature checker 630 at theDFL back end 632.

Imagine thus FIG. 7 the transaction in detail 700. The employerinteracts by generating a Transaction Institution request 702 (throughthe DLF) to the Personal Profile 704 using an API/3rd party approachthat fulfills the Data Package Requests 706. Such a request goes to theData Package Verifiable Information 708 routines, which proceeds toCertify 710 the validity of the requesters SD, at which the informationis shared 712. Any deviations are handled by a Profile Conflict 714.

The above is demonstrated when we see FIG. 8, a financial transaction. Aperson with a DLF is using her mobile phone to buy something (for $100dollars) from a vendor (say Amazon) who already has DLF/IDB enabledtransactions. Amazon (using the SD) knows the person is really her, thatshe is a user of the DLF/IDB, that she is at a Starbuck Wi-Fi spot (andthe Wi-Fi address), etc. Under one scenario 804, the amount of $100 isbelow a pre-determined threshold, and the payment is handled by the DLFsystem internally, using either a built in credit within the systemand/or access to the payment gateway 608 from the user's approvedpayment method.

In an alternate scenario 806, the amount payable is above a threshold,and Amazon decides to use their own payment gateway. However, they usethe ID Broker 602 to verify the user's identity. The IDB 602 proceeds toconfirm the user's identity (who they are 408) by requesting the cellphone's system to take a fingerprint 808 (other options may include apassword, bio-identity, One Time Payment, TAT, TAP etc.), that issomething that proves beyond reasonable doubt that the user is holdingthe phone and acknowledging the purchase. Of course, the actual Amazonto the DLF interface is accomplished by a secure portal (such asstandard Internet plumbing HTTPS and/or similar or enhanced equivalentprotocol).

Depending on the established norms, the IDB 602 proceeds to confirm theuser's identity (who they are 408) by requesting the cell phone's systemto take a fingerprint 808, and also establishes the location (where arethey 406) by asking the Wi-Fi system to verify the location 810 as partof the ‘where am I’ 406 portion of the SD.

In one embodiment, the Wi-Fi bonafides are established by the system. Inan alternate embodiment, the Wi-Fi router bonafides are augmented by theaddition of a geolocation unit, secure attached beacon and/or cryptotoken with secured data storage and protocols). A location aware routerunit, guarantees the “Where am I” 406 portion of the SD, because itestablishes that the units connected to it are connected to a secure andtrusted source that establishes the unit performing any action islocated where it says it is located via first and second sourcegeolocation.

Either the router and/or the computer system connected to it may haveadditional location security via a Physical Access Control (PAC) unit(FIGS. 10-11) which provide either hardwired or wireless networkedconnections and allows for the geolocation of the individual performingany validation or DS, which is then recorded within the TAP. Note asimilar device may be used to act as a POS+Identity Management terminal.A typical PAC has a CPU processor capable of handling DS, as well as oneor more displays 1102, keyboards 1104, fingerprint 1106, RFID or otherbiometric device and if possible a camera. Thus a phone/tablet/computerconnected to a wired/wireless network protected by a router and/or PAClocation, has an increased level of security that is reflected on itssecurity rating.

The interactions with the Smartphone/Tablet/Laptop/Computer may beaugmented by the introduction of programs running on the browser of saiddevice and/or by the execution of applications within the devices. Inone embodiment, the cell phone is a second factor or second level ofconfirmation of the SD. A first level is the password/fingerprint scanthat allows a user to access the phone, as well as the time since theauthentication was done. Thus, someone who ten seconds ago confirmedtheir identity, is much more trustworthy than someone who did 30 minutesago, especially if nothing happened for the last 20 (phone may have beenstolen). Perhaps when a certain threshold is reached ($20), the systemasks for re-authentication by the user.

The above can be seen FIG. 9 when the second scenario. In one embodiment902, an application (or app) 908 (perhaps having a second password ortoken) activates a special Digital Signature 902 or security mechanismwithin the phone, which provides you with a one times password (OTP) 904derived from the electronics ID of the phone 906 (using a hash of thespecific processor ID and other unique chip numbers, and/or as analternate, an offline synchronized crypto routine). In addition. Whensent to the DLF server, this OTP comes in with a PKI DS for the phoneand the OTP. Again, demonstrating that the person who approved thetransaction had access to the phone, and generated an OTP at this time.

In one embodiment, the cell phone re-generates a new OTP password every30 seconds (or any other programmable time interval), based on thespecifics of the user (biometrics, password, etc.), as well as those ofthe phone electronic (CPU, Flash, SD card, SIM card and/or any otherelectronic Unique ID), or may have a Token within it, so the PKI keysmay be generated with an attachment to the phone. It may even be aunique non-removable part of the flash. The public key may be shared so3^(rd) parties may validate the integrity of the messages digitallysigned by the phone.

Following the above, we note how now we create a mobile unit that iscapable of accepting user input (including password, transactionidentity guarantee PKI, bioinformatics (video/facial), password,geolocation, pin), as well as the additional ability to generate a OneTime Passwords based on the unit's information.

In effect, the access to the persons DLF is now a personal depository ofhis/her DLF. When one buy's an iPhone, the product information will beaccrued and made available to the person, so that he/she may keep trackof all the products purchased. Copies of all transactions will bedirectly accrued to my records by separate vendors. In one embodiment,the system works as a centralized secured messages transaction server,so that if an arriving transaction/offer/etc. does not arrived with a DSor certification that validates its provenance and/or TAT/TAP, it'll berejected or sent into a spam folder. So transactions will be eitherphishing, or they will be valid but incorrect, so that I will rejectthem.

Anyone buying a product using their device or unit (phone, tablet, PC,laptop or similar computer system), must then be authorized to the DLFby having access to one or more times. A password, a device, a DigitalSignature inside the device and access to generating an OTP. When theabove is performed at a physical transaction place (say a food truck),your portable device utilizes the SD (augmented with the geolocation ofthe device and/or beacons with secure communications protocols) tovalidate that the portable device was at the particular location whenthe suspected transaction took place.

In an alternate embodiment, the OTP becomes a ‘fortified OTP’ (FOTP). Ineffect, an OTP is a scratch pad (something to be disposed after a onetime use). But a FOTP would allow adding a PKI encryption to a person'sDS. So if you have a previous DS, the OTP is invalid after a certainamount of time has passed (say change the OTP every X seconds). Thus ifsomeone exposes the secret key, it becomes cyclic (so that the keybetween your OTP and the server is reset daily, or within the amount oftime desired).

In one embodiment, the Digital Life Framework (DLF) is comprised of twoprimary computing processing components, an Identity Broker (IDBroker)and an Information Broker (IB). In effect in the DLF system, theInformation Broker received the identity from the IDBroker ID provider.The IDProvider is a computer and communication system that in oneembodiment utilizes OPENID Connect protocols (or similar protocols aswell as custom protocols) to authenticate a user's ID within a system.As such, the IDBroker or IDProvider is effectively the interface to theInformation Broker within the DLF).

In one embodiment, there is an initial enrollment cycle, which may becomprised of one or more of; a background check, information validation,one or more levels of ID credentials creation, generation of ID Card,Token, Password, One Time Password Token (be it hardware or softwaregenerated), server accounts (such as Lightweight Directory AccessProtocol (LDAP) or such similar authentication serve), etc.

Thus, under the DLF, when such a credential is generated within the IDBroker/Manager, ALL the security keys, cards or devices generated arelined to your Digital ID. Since the DLF platform allows for customauthorization transaction protocols, said protocols may be augmented bySatellite navigation systems (e.g. Global Positioning Service (GPS) orsimilar), RF Beacons, Relocation, etc, special electronics orbiological/biomechanical devices.

One or more filters may be introduced at the interface of theInformation Broker and the ID Broker. One of these is a transactionauthorization table. Such a TA table is a high level discriminationtable that identifies which factors or agents in the transaction must beauthenticated and verified. As an example, such a table primarily refersto users or individuals/entities that must authenticate and sign thetransaction, the equipment linked to each said user and the type ofauthentication to be used. Depending on the type of compliance andsecurity required, the encryption keys and handling of the DigitalSignatures (DS), the information may be modified, as there may benotification protocols required per event or transaction.

In one embodiment, the biometrics can also be configurable with severallevels of security depending on transactions. For example, whenfingerprints are used, low security requirements may need only 8 pointsvalidated within the fingerprint, whereas high security applications mayrequire 20 points validated.

In addition to the TA table, or as a replacement for it, a TransactionAuthorization signed path may also be used. This is a feature throughwhich every step of the transaction path is defined (as a level ofsecurity required per device, location, etc.) for every devicethroughout the path in order for the transaction to be considered valid.In one embodiment, every device specified along said path would have asecurity deviation tolerance that would depend on the desiredtransaction security. As such, it may be that every device on the pathrequires geolocation validation, or a user's biometric input (as opposedto passwords), etc.

The InfBroker thus uses the IDBroker plus an Identity Manager todetermine a party's access to the DLF. When the user requesting accessis authenticated and authorized properly, they obtain access to theinformation within their DLF, so they may navigate their profile andaccess their information (and modify any items that may be modifiable bythe user).

One of the pieces of information they may modify, is the addition orremoval of “allowances”, that is, what individual or collectiveinformation about the user may be available to other users that areauthorized/validated DLF users. For example, a user that has finished acollege course or certification may thus broaden the “allowance” totheir Vitae to those having elements identifying them as potentialemployers, government certification agencies or other similar users. Inone embodiment, these “allowances” may be as simple as those used in theHTTP protocol (i.e. Put, Get, Post, Delete).

Within these “allowances”, there is a NOT permit, which allows a User toplace exceptions to access within their DLF profile. As an example,imagine a user who desires to give complete access to a folder havingtheir complete Medical Records, except for Data about their mentalhealth. In such an example, a User of the DLF would provide an“allowance” to all Medical records folder, but place a “NOT” allowanceto those specific to their mental records.

As can be seen, the above is a very powerful weapon with regards topersonal information management. By attaching to each of these“allowances” or permits the IDBroker and InfBrokers (that is, not onlythe exchange of cryptographic keys and signatures, but also theinformation about each step in the path of authentication), each pathfolder or document may have the various levels of crypto keys toincrease their security. Thus an optional Key management module whichhandles said keys increases overall security.

Thus, each allowance may be conditioned with additional security filtersand/or business rules. As an example, the transaction date may have atimestamp field which includes checking any deviations of when thetransaction was executed. Or a time stamp may be generated by the DLFand signed/verified by a separate server, which adds yet another DS tothe transaction. Another basic control field is the amount of times aparticular data field has been accessed. Such a filter controls thenumber of times a particular field has been read or downloaded.

An Auto data destruct filter may be also implemented, so that based onthe number of times a field has been read and the transactional date ofthe data, an auto-destruct routine may be enabled. Multiple Entropy orother data destruction methodologies may be used to destroy and removefrom the system certain fields, while creating an audit trail of suchdestruction that includes who and how the data destruction wasperformed/originated/commanded.

An additional filter may be related to the provenance of the data. Insuch a case, we encounter an authorized DLF user who solicitsinformation and has valid clearance to obtain it, but whose geolocationfor obtaining the data is not valid. In such a case, interaction withthe ID Broker, transaction authorization tables and transactionauthorization path would point to the discrepancies in eithergeolocation and/or device authentication. Such a function wouldeliminate a lot of phishing/meaconing attacks to the security of thesystem.

Yet another control filter may be obtained from knowing if the user paidtheir DLF bill, if their account is up to date, and/or how much isavailable in funds within the account. Such a feature would allow theprotection of both the DLF system administrators, as well as of any3^(rd) parties that may have delegated the payment permit to anotherparty through the system. In this fashion, a user acknowledging apayment gets both a financial or payment status of their account, anykind of special offers based on said status. In one example, imagineyour EZPass account is linked to your accounts via your DLF, once thebalance in your EZPass account drops below a certain level, you receivea SMS, MMS or email alerting you to the low balance, and once youacknowledge the recharge, EZPass or other 3^(rd) parties may use thisaction to offer you additional discount or services.

Locating an archive within the InfBroker may be accomplished in a numberof ways. These include an URL (to locate the document such asdocs/label/filename). The tag and label may be used to create a basicunique document ID. A more advanced ID may be generated by using thetag, label, DS and other mechanisms to generate both a unique ID, aswell as an easy location of the file.

In embodiment of an Authentication Protocol may be based on theTransaction Authorization Table, Transaction Authorization Path and oneor more variables about the user used by the ID Provider. These multifactor authentication (MFA) mechanisms variables may be one or more fromthe group comprised by; Password, Pincode, One Time Password, Biometrics(including Face, Finger, Iris, Veins, Voice and others), Machinegenerated unique codes, Machine Digital Signature, Machine DigitalSignature on a secured cryptographic device token and/or Machinegenerated Unique Code on Secure Cryptographic Device token, LDAP, otherauthentication and/or authorization servers.

Referring to FIG. 13, we see an embodiment of the Digital Life Framework(DLF) back-bone 1300, which is formed by one or more computingprocessing components (typically computing servers with associatedmemory storage 1304 and processors) that perform the functions of AccessControl Services 1302, Bio Service servers 1306, Certification AuthorityServers 1308, Public/Private Key management services 1310, as well asthe other associated databases 1312 (e.g. HIPAA 1322, PCI 1318, FISMA1320). All these services interact with the Identity Broker 602 and theInformation Broker 1314 computing processing elements before crossinggoing out into the Internet 1316.

The FIML and Tricomplete Infrastructure under FISMA control can be seenin FIG. 14, where we illustrate the flow from the internet 1316 throughthe various own and 3^(rd) party vendors web 1402 and applicationservers 1404 culminating in the ID Provider 1406 function. TheImproviser 1406 interacts with the ID Broker 602, who interacts with theBio S 1306, CAS 1308 and Public/Private Key Management services 1310computing processors, as well as with the Information Broker 1314. TheIB 1314 also interacts with the ID Broker 602, as well as the Bio S1306, CAS 1308 and Public/Private Key Management services 1310, ineither the TAT or TAP functions. The Webtrust 1412 or similar complianceinteraction also interacts with the Bio S 1306, CAS 1308 andPublic/Private Key Management services 1310. The Information Broker 1314interacts with the various databases, which in one embodiment includeHIPAA 1322, FISMA 1320, COMDI 1410, PCL 1408 and other associated 1312servers.

As described before FIG. 15, we illustrate the interactions for aGovernment services to an individual's or system user DLF elements. Inessence, for each individual user there is one or more individual blocksegment folder, which has an individual's encryption keys that aremanaged securely based on compliance control needs. The actual data canbe distributed among different servers (both actual and virtual servers,where portions of a server tasks are distributed along two or moreservers) and/or other secure digital media storage means.

Imagine an exemplary sequence where the user goes to a bank and opens anaccount. The bank then uses a terminal with secure devices to perform asecure request for information, like Social Security Data, license,name, address, etc. Using TAT and TAP the terminal interacts with theuser's DLF, and the transaction is signed, sealed and recorded. The usercan then authorize the transaction using the bank's terminal, or theirpersonal mobile secure device (assuming the security levels meet thetransaction security policies, similar to the enhanced certificationscenario.

Referring to FIG. 16, we see how the above would occur with theinteraction of one or more servers holding user information related toDLF, PCI 1318, HIPAA 1322, FIMSL (and/or FISMA) 1320 and SAEII 1602 viatransactions in the back end 1630 through the information broker 1314.Identity Management and Secure Access Control 1632 would be accomplishedby similar one or more computing resources executing the variousfunctions, including; Secure Devices Management 1604, Encryption KeyManagement 1606, PKI-DISSIG providers 1608 (in one embodiment includingan enhanced Certification authority and/or broker authorization server,Authentication Server 1612, ID Provider 1610, Authorization Scheduler1614, Biosecurity provider 1616.

Interactions with the internet 1316 would be regulated by traditionaland enhanced Security Components 1628, including Firewall, UTM, IPS andIDS. Of course, the users 1620, 1622, 1624, 1626. Some users, such asuser 1620, may use augmented security devices 1618, operating throughone or more beacon augmented locations and/or links 1620.

As seen in FIG. 17, third party suppliers 1702 may interact separatelywith the information broker 1314 in accessing the user profile 1706.

An example of the above is illustrated when we imagine a user connectedto their Personal Computer (PC) 202. Using a service such asOPENIDConnect, their web-browser allows them to use standard commands tolog into the DLF. Once OPENIDConnect receives the transaction, the DLFservice provider through the OPENID platform has control to require anyother authentication and/or authorization mechanism variables from thoseidentifies above. Once the appropriate level authentication isestablished, the user is provided authentication and authorization tothe system files.

In cases where biometrics are required, then any and all such mechanismsare accepted, except for the password or pin code option. Such anapplication within the user PC (or Tablet, Smartphone, Laptop or othersuitable computing platform) may be enhanced by the addition of anapplication program (or App), or through the addition of any otherprogram/browser extension which provides physical computer access. Forthe web transaction example above, let's imagine the user has previouslyregistered with the DLF and has valid credentials.

As an example, the steps involved include;

1. Configuring the DLF back-end computing processing devices with theappropriate permissions.

2. Configuring the DLF computing server devices controlling the web-pagesecond factor services with the appropriate permissions.

3. Loading the DLF computing processing server devices and registeringthe client within the device that must be authenticated (e.g. PC,Smartphone, Tablet, Laptop, Special Transaction equipment, Beacon, etc.)

Once the above is done, and the user wants to enter the DLF computingprocessing server devices hosting the web-site, the process comprises;

4. The user attempting to enter the secure website hosted within the DLFcomputing processing servers.

5. The DLF computing processing server devices execute the appropriatesecurity rules and lets the user know the authentication mechanismvariables required.

6. Once the user is properly authenticated via the requiredauthentication mechanism variable, the user is allowed access to thesystem.

7. The DLF system processing component proceeds to establish or requestadditional authentication mechanism variable depending on the leveldesired.

As one example, a user checking general data may be allowed to enterbased on a Password. However, if they decide to access Medical Records,a fingerprint scanner biometric input is required. Once the biometriclevel is required, the DLF system may augment the TransactionAuthorization Table and the Transaction Authorization Path by obtainingthe PC digital signature (including its geolocation data and the path ofauthentication if available), thus informing the user. In addition, anauthentication application within the PC may be accessed to perform thisstep. In another embodiment, the user may be required to use a seconddevice app (say a Smartphone) to establish their bonafides.

An exemplary transaction signing protocol is;

1. The DLF computing processing devices are initialized with a root keyand the appropriate PKI signatures, through one or more of the followingsignature sources; server, application or user.

2. The DLF computing processing device server is authenticated viaserver or application that will execute within it to use the service.

3. An authenticated transaction is received in the DLF server and app.

4. The IDBroker and InfBroker computer components are used to receiveverify and establish if the type of DS received is appropriate to thedata, so the transaction may be signed.

5. The transaction is signed with the appropriate DS.

6. The signed transaction is sent to the user who requested it, and acopy of the transaction is kept for audit purposes.

An exemplary Document signing transaction protocol may be accomplishedvia either hardware or software computer components. If H/W, the PKIkeys are generated in the device performing the signing. When the userwants to sign, the operating system or application knows that the keysare physically in the device memory. Alternatively, if there is acryptographic device provider and the approved authentication methodsconfigured have access to the keys, the physical device may calculatethe digital signature and the information is then signed.

If the computing means want to perform a software digital signing, aprocess of credentialing (credentials generation) regulates the PKIgeneration, either within the DLF computing processing devices or inother computer resources. Within the DLF, said generation of the PKI maybe done by an application at the user's device (PC, Smartphone, tablet,laptop, etc.), or within the DLF computing resources after the login tothe DLF servers has been accomplished, including all appropriateauthentications.

Once a user is within the DLF system, the user determines what documentsto sign and how. In one embodiment the signature may be opaque (such aswith the P7S or equivalent format where the DS is actually in a separatearchive that is compared to), or impregnated, in which case the DS ispart of a document's metadata (such as done in an Adobe or MS Worddocument). In one embodiment, the user selects the type of signature(from the two above) and/or any other additional feature (e.g.timestamp), and signs the document. Specific DS authentication andtransaction rules come into play, and a copy of the transactionparticulars are stored by the system. Of course, the signed document maythen be shared through the DLF with others, via file locations, securemessaging or other digital means such as email.

Another DS method may be one performed by proxy. A person that wants tosign a document (say from their Smartphone or cellular), but has limitedability to read the complete document (say they cannot fully downloadit), may decide to DS using the biometric or other interface from theSmartphone and the DS present in the DLF computing servers, as long asthe transaction authorization tables and/or transaction authorizationpath protocols are followed. The above may also occur if the Smartphonehas a DS (in either H/W or S/W).

When using the proxy method, the DLF computing server having thedocument calculates a unique mathematical hash or DS of the document tobe signed. The document is then signed with the Smartphone applicationDS and another from the DLF server. The DLF server then sends a requestfor DS authorization of the document, including in the request theinformation about what document is being signed, the DS to be used andthe policies to be used once the document is DS.

Once the user receives said information on their Smartphone or device,they authorize the proxy DS and this authorization is signed by theuser's device at the point where the transaction is being performed (viaGeolocation), as well as their DS through the transaction authorizationtables (TAT) and/or the transaction authorization path (TAP).

In yet another protocol, a Beacon Authentication may be used toestablish the DS. In this embodiment, we utilize the existence of one ormore RF beacons that have been installed and registered in specificareas (say an office building or shopping mall, with one or more beaconsper store). The mobile device (Smartphone, cell, tablet, laptop,phablet) has an app or physical interface capable of interacting withsaid RF beacons.

The App within the mobile device can interact with the beacons,establishing the uniqueness of each beacon through a uniqueidentification (say a number that may be validated) so that the RFbeacon may be established and their DS trusted.

When identifying the geolocation based on the input from multiplebeacons, the App or auxiliary device linked to the mobile devicesequentially captures and updates the identity of the various beaconsaround it, receiving their ID and timestamp. When a transaction needs tobe executed (say the purchase of an item at the store), the identity andlocation of the various beacons encountered during an X amount of timeis corroborated and correlated. Thus, at the time of the transaction(purchase, DS, authorization), the number and position of the beaconswithin range is communicated and/or the beacons registration log in an Xamount of time. Their location, existence, values, may then be used toauthenticate the geolocation of the mobile device.

In the case of fortified beacons (that is, those beacons capable ofemitting a signal and receive multiple signals including SatelliteNavigation signals, DS, and other cryptographic security features), thecommunication and tracking function is even stronger, as it can create abeacons map that is synchronized with the DLF security services, TAT,TAP, PAC, etc. If the beacon system is tied to security cameras andmicrophones, the camera view may be pre-configured towards the locationof the beacon at a time identical to the transaction, so that areference of the transaction may be store via visual imagery or audiorecordings (perhaps even biometrics derived from the sensors) in orderto verify the transaction.

The fortified enhanced certification authority protocol corrects severalissues/shortcomings experienced by the CAS. CAS suffers, among othersfrom; extensive background checks that can be manipulated; oncecertification is given, information is not re-verified and/or updated;the nature of a digital certificate is to provide for user a digitalcertificate that contains information that can be verified by the CAS.This certificate contains the PubK (Public key of the user and all ofthis is digitally signed by the CAS, under its “Certification AuthorityRole”. As an example, a typical digital signature certificate containsCommon Name, Title, Address, Email Organization, Organization Unit;Country, State, Public Key, etc.

That is, a typical CA does not keep track of who got a copy of thecertificate. With the verified information of the user which in manycases is information (name, etc.) that can be considered confidentialand could be used for identity theft. The CA does not have the capacityto certify the user information per transaction in which the signatureis used. For the CA to update the information in the certificate, itneeds to revoke the certificate and emit a new one, a time and resourceconsuming process.

In contrast, the proposed Fortified Enhanced Certification AuthorityBroker (FECAB) offers a solution through the creation of a CA that canguarantee multiple types of transactions related to the CA and exchangeof any information certified by the CA. The user would have multiplecertificates with different purposes and/or different information inthem. Proxy certificates with minimum user information would be createdfor digitally signing or encrypting information requests.

By adding the security controls of the IDBroker 602, the CA canimplement the TAT and TAP protocols as well as other custom protocolsfor the operation of the CA, the key management and all lifecyclemanagement of the data. Adding some functionality that are not beingimplemented under present procedures.

The Dynamic Certificate Protocol would use the following;

1. Proxy certificates are used to validate the request of information orrequest for use high grade certificates.

2. Once the request is received, authenticated and authorized, the CAengine communicates with IDBroker 602 and Information Broker 1314 toverify any update to the information of the certificate.

3. If the information is correct, the transaction is authorized with therequested high grade certificate.

4. If the information is updated, the previous certificate is revokedand a new one issued, notifying the TAT and the TAP.

In addition, the user has the capacity to have a transaction certificateof the protocol. In such a case, the user follows the same requestprotocol or similar one using the proxy certificate in connection to theTAT and TAP (if necessary).

Once authorized, the user receives a specific certificate that is validfor that specific transaction or similar transactions. After thetransaction is finished, it is in effect a digitally signed contract. Inone embodiment of the protocol, the document/contract is in thendigitally signed the DLF timestamp server. In a similar embodiment, thedocument is signed using MFA.

A log of the transactions and timestamps may be generated once thetransaction is finished and recorded, so the user has the abilityautomatically revoke the certificates without invalidating thesignature. This, because at the moment the certificate was used and timestamped with the TAT and/or TAP if necessary the transaction can then bevalidated. Through the above mechanism, we are in effect creating aunique way to create a different mechanism for digital certificateslifecycle legality and management.

The DLF components may be extended to become a Secure ID Broker withintegrated VoIP communication and video conferencing. Voice over IP(VoIP) communication systems suffer from different security issues. In ascenario where both users are using the DLF ID Broker Secure VOIP basicprotocol, User one authenticates with the VOIP service using our DLFSecure ID Broker Internally the Broker chooses the appropriate protocolsof authentication, authorization and related signatures, encryption keysand notification parameters.

Once all internal processes are completed (this processes and protocolscan be custom programmed depending on security needs) the call is sentvia an encrypted or non encrypted channel depending once again in theuser and security policies. Call recipient user receives notification ofa verified call, and a notification of the level of trust and securityof the call is presented to user via voice, text, descriptive color, orany desired graphical user interface. The user has the capacity ofrecording the conversation and use several other security andauthentication or business related features while in the conversationreal time.

When the call or communication session is terminated, a secured anddigitally signed notification message is sent to the information brokerand depending on the business and security policies with the attacheddigitally signed digital format of the conversation. This informationcan be sent encrypted to the information broker if necessary.

In a similar approach, a Fortified multiple business platform scenariomay be executed. Whereas a typical payment gateways are limited tospecific transactions and limited mechanism of authentication. Paymentgateway are also use only for financial related transactions thatcommunicates via API's or SDK with 3^(rd) party integrators that haveonline e commerce transactions. With a fortified implementation, wewould have a unique secure payment gateway with multiple businesstransaction engine so the user can create an online store with differentbusiness models such as: payment gateway, products, services, booking,fundraising, biding, Ticketing for events, pooling, etc. Some of thefeatures include inventory management, virtual currency, reward pointsmanagement, scheduling and calendar, among others.

By having this framework with predefined business models and combinedwith the DLF the user with have a capability of creating and managingnot only personal but business transaction within the same platform withthe highest grade of transaction and authentication security.

Referring to FIG. 18 we see the typical Certificate process. FIG. 19illustrates the ID broker components, said ID broker a criticalcomponent of the Certification authority, including ID Provider,Authorization and other similar listed components. In particular, wenote the CAF, which may include two or more Certificate Authorities.FIGS. 20-21 illustrates exemplary components for each of the proposedbuilding blocks. You notice the ID Broker is related to mechanisms anddevices to ensure your digital life, with a focus on mechanisms andtools and authentication data to identify the user or individual, notthe actual information that wants to be accessed or shared.

For example the ID Broker deals with the authenticity of the userrequesting a medical record, and once authorized/authenticated, theactual medical data about someone is provided by the Information Broker(FIG. 22). The Information broker has various blocks that communicatewith the ID broker, through the DLF (FIG. 23). FIG. 24 shows an exampleof an interaction between multiple information brokers (e.g.public/government/private entities). As such the Government (left side),may have the same data (or similar), or make anonymous transactions.

FIG. 25 illustrates the Information Broker/ID Management brokerintegration, but with the ID information being shared with third parties(e.g. social media, Electronic health records), etc. FIG. 26 illustratesthe components to be integrated within the various portions of the DLFin its commercialization within various businesses. FIG. 27 also showsthe topology of the Information Broker and the ID broker. FIG. 28illustrates a similar topology.

A public key certificate or digital certificate is a digitally signeddocument that serves to validate the sender's authorization, name andother roles. The document consists of a specially formatted block ofdata that typically contains the name of the certificate holder (whichmay be either a user or a system name) and the holder's public key, aswell as the digital signature of a certification authority (CA).

In one use, such a document may be used, among uses, for authenticationof said user. The certification authority attests that the sender's nameis the one associated with the public key in the document. A user IDpacket, containing the sender's unique identifier, is sent after thecertificate packet. There are different types of public key certificatesfor different functions, such as authorization for a specific action ordelegation of authority. Public key certificates are part of a publickey infrastructure system that deals with digitally signed documents,among others. The other components are public key encryption, trustedthird parties (such as the certification, verification validation andregistration authorities and implementation guidelines among others),and mechanisms for certificate publication and issuing.

The standards and services that facilitate the use of public-keycryptography and X.509 (and similar other formats) version certificatesin a networked environment are collectively called public-keyinfrastructure (PKI). In any PKI, a certificate authority (CA), is atrusted entity that issues, renews, and revokes certificates for auser's (sometimes called also end entity), who are a person, router,server, or other entity that uses a certificate to identify itself toothers in the internet.

To participate in a PKI, such users (including as stated above bothnatural persons, corporation and devices, commonly known as end users)must enroll, or register, with a CA (in this case functioning as aRegistration Authority, or RA). The end user typically initiatesenrollment by (FIG. 29) generating a public/private key pair, andsending to a Registration Authority (RA) (the RA may or may not be aCA), by sending a request for a Certificate, providing the RA with theuser information (Data Fields A through Z), providing the user PublicKey (PubK), and digitally signing the file (using the user's Private Key(PrK).

In another embodiment, the example of a digitally signed file itcontains the Raw data file, a certificate containing signer user publickey and user public data the digital certificate also includesinformation about the CA and is digitally signed by CA. A digitalsignature of the file is included and was created by using user privatekey that matches the public key of the certificate.

The information provided may include one or more of the user's unique ID(e.g. Social Security and/or National Number), email, address, licensenumber(s), servers request, etc., i.e. information expected to be knownonly by said user. The RA validates the data, typically through otherparties, and affirms to the CA that this request is from said user.

Once the RA (or the CA in its capacity as and RA or via a third partyRA) uses said provided information to authenticate, confirm, and/or inother fashion confirm said data, establishes the requesting party (user)bona fides. In some cases the CA may require human intervention,including a phone call, interview, examination of notarized documents,biometrics, etc. in order to authenticate the user's bona fides. Inother cases the information provided may be sufficient (automaticapproval).

In addition to authenticating the user via the above process, the CAuses the public key to ensure “proof of possession”—that is,cryptographic evidence that the certificate request was signed by theholder of the corresponding private key. Finally, the CA issues thecertificate, which has the user information (A . . . Z), the user PubK,associated CA information (including technical information about thetechnology used and the activation/expiration dates for saidcertificate), and is finally digitally Signed by the CA, including saidCA's PubK. (Again, the PrK are never publicly shared). From now on,every time the user wants to establish its bona fides, it simply usesthe Certificate to digitally sign documents or otherwise establish itsbona fides.

The above process (as shown), is fairly data intensive, and marketconditions have forced the setting of said expiration dates to a fairlylong period, typically one to two years. Also, once the Certificate(CERT) is issued to a user, he/she/it may use it within the internet atany time. While Certificates are sometimes recalled/cancelled, they areusually accepted as valid.

When signing a document or transaction (FIG. 30), the user generates anelectronic file that includes the action or actionable document (forexample a file to be signed 3002, the CERT 3004 and a Hash 3006 that isgenerated with a combination of the File/CERT and the User PrK (the onepaired with the User PubK used in generating the CERT and that ispresent on said CERT). To validate the validity of said digitally signeddocument, the receiver need only validate the Hash using the User PubKpresent in the CERT.

We term as a Certificate authority computer system as the collection ofservers, application (apps), and communication links (both securedand/or unsecured and/or combinations thereof) that communicate thepertaining information. When obtaining a PCERT, users must typicallysend their actual information and/or pointers (in the form of URL orother direct link to files/web-sites/pages, etc., wherein theinformation resides (not unlike either giving your name and/or alocation where your actual name resides). We term this actualinformation about the user as proxy request data elements, and fields Athrough Z.

The CA (through a 3^(rd) party Registration Authority or other parties)verifies this information, and generate a set of PCERT data elementsthat are ‘related’ data fields and/or contents A′ . . . Z′. These forexample, change your name from Luis to Buho123, or even a unique numberor alpha. It is this one or more PCERT data fields (A′ up to Z′) thatare used to generate the PCERT. Such of course, allows the authorized CAto understand that Luis is requesting a TCERT with Luis, but that thePCERT says Buho123, making the PCERT all but invalid for use in the opensystem in some cases, it also guarantees that TCERTs have the actualdata. When generating the PCERT, the ancillary data in some cases mayinclude a new PubK/PrK pair for the user generated by the CA, sometimesnot.

When a user requests a TCERT, they identify the data/field names/pointerand/or tokenized data they want in the TCERT, and when this arrives atthe CA, said CA matches said A . . . Z data with said A′ . . . Z′ datafor said user (with or without a PCERT as explained below), thenproceeds optionally to validate said data A . . . Z at the time ofissuance of the TCERT (which may be valid for as long as a CERT, but mayalso be valid for seconds or less) and may even use MFA to validate thatsaid user is said user. In this fashion, the short duration of thecertificate obviates the hard problem of a TCERT's validity two yearsfrom now.

In one embodiment, a typical CA operation example has a user provideinformation to RA/CA so it can be validated by CA, the certificaterequest is digitally signed by the user local new generated key pair.Once the information is validated and the certificate is created by theCA and is digitally signed by the CA. The new certificate is sent to theuser. The certificate lifecycle is managed by the ca with user input.

The proposed solution uses the same arrangement for CERTs, but it doesso through (FIG. 31-32) the emission of a proxy certificate (PCERT),which would be obtained by the user through a procedure similar totoday's Certificate, but would not be intended for use in the ‘generalpopulation’ (that is, to validate ‘openly’ with others within theInternet), yet would last a significantly long time (as much as today'sor longer).

In one embodiment, a PCERT request with locally generated key pairoccurs as this. A User using a selection of interfaces) provided by CAincluding but not limited to software applications, hardware specificdevices, webpage, web services, mobile apps, and other electronicpossible interfaces, these software application creates the specificdata packets and formats as required by the RA/CA. As part of therequest process, Locally at user device it is generated a key pair andit's private key is used to digitally sign the PCERT request. As part ofthis process Multiple Factor Authentication can be used if necessary.All of this information is sent to RA/CA by the request interface viasecure or unsecure channels, depending on CA and user policies.

Once the information is decoded, verified and or validated following allsecurity protocols, policies and procedures that may include multiplefactor authentication depending on transaction or data elements to bevalidated by RA/CA. The CA proceeds to create a (Proxy DigitalCertificate-PCERT) digital certificate with the specific data fields,references, data links, visual references, tokens, and otherrepresentation and structures required by CA for the PCERT and userauthentication and authorization. The digital certificate is digitallysigned by CA and the time of validation is determined by security andtransaction policies. All certificate lifecycle including revocation ismanaged by CA and user depending on the policies mutually agreed.

In one embodiment, when registering and obtaining PCERT, it acts as aproxy authorization and or authentication certificate that can be usedwhen a temporary certificate want to be produced or any other authorizedtransaction by the user with the CA.

In one embodiment, to obtain the PCERT, a user sends the similarinformation (where as today, the actual field information, i.e. ActualName, License Number, Address as in Joe Smith, USPTO Reg. 58,300, OneMain Street, Nashua, N.H.) is sent to the CA, is validated by the RA(again, or a CA acting as an RA), and then generates a ProxyCertificate).

In one scenario the user requests a key to be created with keys createdon local computer, device, mobile phone, hsm, etc. Information to bevalidated in RA/CA is sent via a secure or unsecured channel to RA/CA(Said Registration Authority, Certificate Authority and/or combinationthereof). Besides the information sent to be validated, validates theinformation via multiple ways and it can include multiple factorauthentication protocols depending on business rules. Using the clientcertificate request software or hardware a PCERT certificate request isgenerated using locally generated key pair (PubK/PrK).

Once the RA and/or CA validates the information a PCERT is created anddigitally sign by the CA, the fields of data or pointers in the PCERTare only understandable and for use with the CA. PCERT does not containany data that identifies the user, the only one that can identify theuser is the CA. PCERT is delivered to user and is digitally signed byCA.

In another scenario, said PCERT is created with keys created on the CAdirectly. Information to be validated in RA/CA is sent via a secure orunsecured channel to RA/CA. Once RA & CA validates the information viamultiple ways and it can include multiple factor authenticationprotocols depending on business rules. Keys for the PCERT are created bythe CA and digitally sign by the CA, the fields of data or pointers inthe PCERT are only understandable and for use with the CA. PCERT doesnot contain any data that identifies the user, the only one that canidentify the user is the CA with internal mechanism. PCERT is deliveredto user and is digitally signed by CA. For the use of the PCERTdepending on the security rules by user and CA it can require multiplefactor authentication when it is used. If desired a user can havemultiple PCERT depending on the type of data and security rules.

In one embodiment, the validation in addition requires Multi FactorAuthentication, at the time of PCERT issuance. The user then stores thePCERT in their machine for use anytime a Certificate is required. TheseCertificates for ‘open’ use are now Transaction Certificates (TCERT).

A TCERT—Temporary Digital Certificate is a digital certificate that hasa temporary use of life (Seconds, minutes, hours, days, years) and orlimited to a specific transaction or transactions. The CA re-validatesin real time the fields prior to generate the TCERT and in case anyinformation is needed based on the policies it manages the relation withthe final user so the required information is updated by user.

The TCERT can have various formats of operation and data structures, Itmostly use but is not limited to X509 standard since it can includesreference files, references or links to actual certified or approved todisplay data, it can also contain displayable graphical encoded inexample in (encrypted or not 1D (barcode), 2D (DataMatrix, QrCode,PDF417), visual stenography, sound watermark, etc) that can be attachedor implemented in the certificate or as an attachment to the file thatneeds to have the verifiable data. This while many other approved datastructures that can be custom based on requirements.

The Validation of the data fields of the TCERT are depending user,organization and or compliance rules for such data. In case a TCERT isusing reference data or links, actual data can require multiple factorauthentication depending on security policies. Certificate RequestProgram definition—Cert Request program is a special version that cancomply with PCKS10 Standard but is not limited to it since it hasvarious functionalities that expand the security and usability of it.

There are various scenarios for obtaining a TCERT. In one embodiment,the party requesting a TCERT using local generated keys and providingall data elements in the request either by putting the information ofthe required fields. In this Scenario the CA only verifies that theinformation sent by the client request APP is correct. It uses the PCERTas an authorization mechanism for the CA to generate a new certificateon behalf the user information on the certificate request. In this casethe user uses the client APP or webpage, a new key pair is generated.

The user fills out all the data fields that is going to the actualTCERT, this information is sent via a secure or unsecured channel to theCA. and the request is digitally signed by the new key pair private key.All the transaction apart is digitally signed by the PCERT as part ofthe authorization and authentication process. The CA receives theinformation and verifies the following: That the data entered by theuser is exactly as the one it has in the internal records. All internalvalidation policies, security policies, business rules it can usemultiple factor authentication depending on security rules and policiesby CA and user or organization. When everything is validated the CAgenerates and digitally signs the TCERT with the CA digital signature.

In another embodiment, the party requesting a TCERT using localgenerated keys and providing only field names, tokenized field names ortokenized data elements. In this Scenario client APP will have allrequired security and algorithm mechanism to produce the configurabletoken that can represent a data field name, or specific data elementthat the CA will validate prior to produce the new TCERT. In oneembodiment, there a request APP sending it. Said APP uses the PCERT asan authorization mechanism for the CA to generate a new certificate onbehalf the user information on the certificate request.

In this case the user uses the client APP or webpage, a new key pair isgenerated. The user fills out all the data fields that is going to theactual TCERT, this information is sent via a secure or unsecured channelto the CA. and the request is digitally signed by the new key pairprivate key. All the transaction apart is digitally signed by the PCERTas part of the authorization and authentication process. The CA receivesthe information and verifies the following: That the data entered by theuser is exactly as the one it has in the internal records. All internalvalidation policies, security policies, business rules it can usemultiple factor authentication depending on security rules and policiesby CA and user or organization. When everything is validated the CAgenerates and digitally signs the TCERT with the CA digital signature.

In on embodiment, when interested in obtaining a TCERT (FIG. 33), theuser contacts the CA with the desired information in the TCERT (again,having the actual data in the fields), and is sent to the CA togetherwith the Proxy. The CA receives said request, and generates the TCERTbased on the validity of the user, the Proxy, etc. While TCERTs may bemade with any duration of time as validity, they are by nature bettersuited to have very short durations (say minutes, hours, days). In thisfashion, one embodiment may be one where TCERTs are designed to be usedby transaction (say when digitally signing an individual US PatentApplication document), or by days (TCERT for the week or month), etc.

In an alternate embodiment, a User using a selection of interfacesprovided by CA including but not limited to software applications,hardware specific devices, webpage, web services, mobile apps, and otherelectronic possible interfaces, these software application creates thespecific data packets and formats as required by the RA/CA. In this casethe key pair of the PCERT is not generated locally in the device. All ofthis information is sent to RA/CA by the request interfaces via secureor unsecure channels, depending on CA and user policies.

Once the information is decoded, verified and or validated following allsecurity protocols, policies and procedures that may include multiplefactor authentication depending on transaction or data elements to bevalidated by RA/CA. The CA creates a new key pair that contains both thepublic and private key of the new to be created PCERT. The CA proceedsto create a (Proxy Digital Certificate-PCERT) digital certificate usingkey pair generated by CA and with the specific data fields, references,data links, visual references, and other representation and structuresrequired by CA for the PCERT and user authentication and authorization.The digital certificate is digitally signed by CA and the time ofvalidation is determined by security and transaction policies.

All certificate lifecycle including revocation is managed by CA and userdepending on the policies mutually agreed. Said PCERT is sent in aportable format containing the public and private key (ie. Pfx, .cer,xml, JSON, any custom format, etc). This portable file can be protectedusing multiple factor authentication if is necessary.

In an alternate embodiment, when receiving the TCERT request, the CA inaddition to validating the Proxy, validates the status (when applicable)of the Data Formats. For example, is your address still the same, hasyour USPTO Registration expired? Has your Engineering license beingrevoked? In addition, in another embodiment, the CA may use MFA toauthenticate your TCERT. Said MFA includes at least one of the followinguser interactions: telephonic, password, biometric, token (H/W and/orS/W), Password, Pincode, One Time Password, Biometrics (including Face,Finger, Iris, Veins, Voice and others), Machine generated unique codes,Machine Digital Signature, Machine Digital Signature on a securedcryptographic device token and/or Machine generated Unique Code onSecure Cryptographic Device token, LDAP, other authentication and/orauthorization servers.

Once the data is validated and/or MFA'd, the TCERT is issued and sent tothe user for his/her/it digital signature in public use. Again, a TCERTis of shorter duration lifecycle, but similar to a regular certificatein that it is intended for use in the open market. That is, TCERT isthen used to digitally sign any document that the user is interested indigitally signing.

The above however, provides for additional options when generating theTCERTs that are no available today. In one embodiment, FIG. 33, there isa need for an additional step or interaction between User and CA, but atadditional security.

In one embodiment, a User using a selection of interfaces provided by CAincluding but not limited to software applications, hardware specificdevices, webpage, web services, mobile apps, and other electronicpossible interfaces, these software application creates the specificdata packets and formats as required by the RA/CA. This data can be thedata required, and or data field names and or pointers and or tokenizeddata for data fields content and names. As part of the request process,locally at a user device it is generated a key pair and it's private keyis used to digitally sign the TCERT request.

This TCERT request authorization is also digitally signed by the PCERT.As part of this process Multiple Factor Authentication can be used ifnecessary for the PCERT and or TCERT. All of this information is sent toRA/CA by the request interface via secure or unsecure channels,depending on CA and user policies. The information of the request isdecoded, verified and or validated following all security protocols,policies and procedures that may include multiple factor authenticationdepending on transaction or data elements to be validated by RA/CA.

The CA proceeds to create a (Temporary Digital Certificate-TCERT)digital certificate with the specific data fields, references, datalinks, tokens, visual references, and other representation andstructures required by CA for the TCERT and user authentication andauthorization. The digital certificate is digitally signed by CA and thetime of validation is determined by security and transaction policies.All certificate lifecycle including revocation is managed by CA and userdepending on the policies mutually agreed. Explication on types of datafor data request or data on certificate—This data can be the datarequired, and or data field names and or pointers and or tokenized datafor data fields content and names

The user who desires a TCERT begins by generating a request for a TCERT,by sending a request, specifying that he/she/it would like a TCERThaving one or more of the specified data fields (FIG. 34) (but not thespecific data to be included in it), which is signed by said User'sProxy. The CA validates that the data fields actual data is still valid(is the Name/License/Address still valid). A point on this, many womenchange their last name when they marry, and also many computers changetheir name as part of an acquisition, the above system would allowpeople to keep their Proxy by simply updating the information with theCA through separate steps.

In one embodiment, the TCERT Request with TCERT key pairs generated onCA and no PCERT Authorization. A Variant scenario is the same scenarioas FIG. 34. The only difference that the PCERT digitally signedauthorization is sent in the TCERT request process. In such a User usinga selection of interfaces provided by CA including but not limited tosoftware applications, hardware specific devices, webpage, web services,mobile apps, and other electronic possible interfaces, these softwareapplication creates the specific data packets and formats as required bythe RA/CA. This data can be the data required, and or data field namesand or pointers and or tokenized data for data field's content andnames.

In this case the TCERT key pair is not generated in the user device andthe PCERT is not present for the TCERT creation authorization. (In thecase of the variant A of this figure the PCERT is present and digitallysigned the authorization of the request). As part of the requestprocess, the RA/CA communicates online or offline with the user and aspart of this process Multiple Factor Authentication can be used ifnecessary for the TCERT authorization with the required fields. All ofthis information is sent to RA/CA by the request interface via secure orunsecure channels, depending on CA and user policies.

The request and information is decoded, verified and or validatedfollowing all security protocols, policies and procedures that mayinclude multiple factor authentication depending on transaction or dataelements to be validated by RA/CA. The CA creates a new key pair thatcontains both the public and private key of the new to be created TCERT.The CA proceeds to create a (Temporary Digital Certificate-TCERT)digital certificate with the specific data fields, references, datalinks, tokens, visual references, and other representation andstructures required by CA and requested and authorized by user.

The digital certificate is digitally signed by CA and the time ofvalidation is determined by security and transaction policies. Allcertificate lifecycle including revocation is managed by CA and userdepending on the policies mutually agreed. Said TCERT is sent in aportable format containing the public and private key (ie. Pfx, .cer,xml, JSON, any custom format, etc) this portable file can be protectedusing multiple factor authentication if it is necessary.

In another embodiment, the CA validates the data and optionally performsone or more MFA's, and generates a TCERT that has the actual A, B, X, Qfields data (that is, actual names, address, etc.), which goes to theuser. The User then takes the actual A, B, Q, X data, and uses its proxyto generate a TCERT request to the CA (similar to the example above). Inthis case, the user may use its original PrK/PubK, or generate a new setof keys for this transaction. The CA takes the ABXQ/Proxy package, andgenerates a TCERT, which the user may use to sign his/her/it documents.Note in both cases above, the user is in FULL control of generatingPrK/PubK pairs, not needing to risks these in transmission.

In another embodiment, the actual fields (FIG. 35) are not even thenames of the fields, but one or more pointers to secure locations wherethe field identification and/or actual field information is held. Inthis fashion, the user does not even identify the actual nature of theinformation to be contained within the field in any transmission (itwould be easier to crack the code for a field that is known to benumeric (say SSN or USPTO Registration Number).

In one embodiment, we see a request that does not include actual datafields of the request, it only has the data field names and or datapointers and or tokenized data fields name or data. The keys of theTCERT are generated in the User device. In a variant the only differencethat the request does not include the PCERT digitally signedauthorization). In either case, a User using a selection of interfacesprovided by CA including but not limited to software applications,hardware specific devices, webpage, web services, mobile apps, and otherelectronic possible interfaces, these software application creates thespecific data packets and formats as required by the RA/CA. This datacan be the data field names and or pointers and or tokenized data fordata field's content and names, in this case the RA/CA will send theuser the actual data fields values that is going to be used in the TCERTrequest.

As part of the data request process, the RA/CA communicates online oroffline with the user and as part of this process Multiple FactorAuthentication can be used if necessary for the PCERT authorization withthe required fields. All of this information request of data is sent toRA/CA by the request interface via secure or unsecure channels,depending on CA and user policies. In this case the request is todownload from the RA/CA the actual data that will be used to request theTCERT. This information request will be authorized and signed by thePCERT (In the case of the variant A of this figure the PCERT is NOTpresent)

The request for TCERT data values download and information is decoded,verified and or validated following all security protocols, policies andprocedures that may include multiple factor authentication depending ontransaction or data elements to be validated by RA/CA. The RA/CA sendsthe data of the fields that will be used by the user to request theactual TCERT. This information is sent via secured or unsecured channeldepending on RA/CA and user policies. The user now using any of theinterfaces now create the TCERT request with actual all data elements.

As part of the request process, locally at a user device it is generateda key pair and it's private key is used to digitally sign the TCERTrequest. Using the interfaces the USER TCERT REQUEST IS SENT TO RA/CAand is approved and digitally signed by the PCERT (in variant a of thisscenario the PCERT is not present). Since all data has been alreadyvalidated for downloading the data that is being use in the TCERTrequest, there is no need to revalidate once again to create the TCERT.

The CA proceeds to create a (Temporary Digital Certificate-TCERT)digital certificate with the specific data fields, references, datalinks, tokens, visual references, and other representation andstructures required by CA and requested and authorized by user. Thedigital certificate is digitally signed by CA and the time of validationis determined by security and transaction policies. All certificatelifecycle including revocation is managed by CA and user depending onthe policies mutually agreed. The TCERT is sent to user via interfaceand under secured or unsecured channels depending on CA and usersecurity policies.

In one embodiment, the system obviates the need for the extra back/forthstep (FIG. 36) by generating TCERTs that have the full information fromthe file, and sending the TCERT and the PrK/PubK pair keys used togenerate them to the user a the first step. The pointer within saidcertificate may be one to the Viral test results in an EHR held withinthe Medical system.

In one embodiment, the request does not include actual data fields ofthe request, it only has the data field names and or data pointers andor tokenized data fields name or data. The keys of the TCERT aregenerated in the CA. and a PCERT is used to authorize the TCERTcreation. (In the variant a of this scenario the PCERT is not used forthis authorization. A User using a selection of interfaces provided byCA including but not limited to software applications, hardware specificdevices, webpage, web services, mobile apps, and other electronicpossible interfaces, these software application creates the specificdata packets and formats as required by the RA/CA. This data can be thedata field names and or pointers and or tokenized data for data field'scontent and names. As part of the data request process, the RA/CAcommunicates online or offline with the user and as part of this processMultiple Factor Authentication can be used if necessary for the PCERTauthentication and authorization with the required fields.

The Information required is sent to RA/CA by the request interface viasecure or unsecure channels, depending on CA and user policies. In thiscase the request is to request the TCERT with the CA filling out all ofthe values of the TCERT including the key pair. This information requestwill be authorized and signed by the PCERT.

In another embodiment, the PCERT is NOT present and the request forTCERT with its data values and information is decoded, verified and orvalidated following all security protocols, policies and procedures thatmay include multiple factor authentication depending on transaction ordata elements to be validated by RA/CA. The CA Creates a new key pairthat will be used for the TCERT. The CA proceeds to create a (TemporaryDigital Certificate-TCERT) digital certificate with the specific datafields, references, data links, tokens, visual references, and otherrepresentation and structures required by CA and requested andauthorized by user.

The digital certificate is digitally signed by CA and the time ofvalidation is determined by security and transaction policies. Allcertificate lifecycle including revocation is managed by CA and userdepending on the policies mutually agreed. The TCERT is sent to user viainterface and under secured or unsecured channels depending on CA anduser security policies.

In another embodiment, the actual field identification is not a pointer,but a token identifying it for a limited amount of time, so that thepointer is only valid during the limited window.

In one embodiment, we have a special certificate request platform—forall of the scenarios the certificate and information request is done viaan integrated platform. It includes multiple component and it's notlimited to secure cryptographic functions, hardware security modules,Secure Random Number generators and can be implemented in multipleOperating System including custom programmed hardware devices.

As part of the formatting of the request, the system can provide thefield data names, links to actual data so it can be verified, securedlinks with credentials so information can be accessed, visual dataelements represented in either encrypted or not encrypted 1 and 2Dbarcode, QRCode, visual stenography and or digital watermarks that canbe read via an electronic device and or human eye, or only a specificelectronic device with the unique characteristic to red and decode thedata.

Tokenization example is defined as a Time based One-time passwordalgorithm (OTP) defined in RFC6238 and namely the HMAC-Based One-timePassword, as defined on RFC4228 both of this examples can be located bythe Internet Engineering Task Force. In the example and context of thistransaction One Time Password Tokens can be used to hide data that onlyclient and server can understand. For example data field name,authorization and authentication, and other specific required dataelements for the transaction to occur.

For example let's assume a certificate request needs to have thespecific fields that need to be validated and implemented in the newcertificate provided by the CA. In this scenario in the request insteadof saying for example (Request, fields (Name, Last Name, Title, link tofile), Verify(authentication code1, authorization code2)).

An example of the request explained above can look similar like this

(Request, fields (11234, 44214, 223467, 213464), Verify(5567543,1223567))

Taking in consideration that numeric or alphanumeric code change in aconfigurable time set like specified in the RFC or any other customprotocol. This methodology is different than regular or typicalencryption since it's time based. It is recognize that multiple keysdepending on the final implementation in a case by case basis, thiswould be required and each interface implementation may protect thissecret keys in different ways via software, hardware, hardware securitymodules, specialized devices, etc. It is also taken into considerationsecure key management protocols for sharing of any key or keys.

All communication with the Server from client and vice versa can befully encrypted using multiple encryption tunnels and protocols such as:SSL, TLS, SSH, VPN, IPSec and other protocols either standard or customprogrammed security protocols that include symmetric, Asymmetric and anyother type of encryption and methodologies that protects data from beingread by a unauthorized third party. On example of a security protocol isthe Tokenized sharing mentioned here above and any other data securetransfer custom made to identify and protect data.

It is also provided that for the ENCAB data communication, protocolssuch as: (TAT, TAP, etc), multiple authentication mechanism, digitalsigning tools and information sharing can have the capacity to integratewith the Information Broker, Identity Broker and Digital Life Frameworksoftware and hardware devices.

As part of the ENCAB process digitally signing files data andtransaction and keeping track of the transaction is important fortransaction monitoring and integrity. This is why the ENCAB can includeif necessary a separate file and data signing tools for online andoffline cases. For this process once the TCERT is provided to the userthe user can digitally sign any document or file using the CA singingtools. The digital signing tools are via desktop application, web basedapplication and or web services or other electronic services. Itprovides the capacity of multiple factor authentication every time adocument would be signed, this based on the system configuration andsecurity policies to be synchronize with the ENCAB.

In the case that the signing tools digitally signs the document onlineusing a portable CERT FORMAT hosted online by the digital signing toolprovider. A digital authorization form, data, tag can be digitallysigned by either a PCERT, TCERT or authorized CERT. Multiple Factorauthentication can be used for the authorization form signatureimplementation. The signing tool can also provide a visual reference(1D, 2D, Qrcode, visual stenography, Watermarks, etc) separate from theENCAB but also can synchronize with the ENCAB references so there istotal tracking not only on the TCERT creation and lifecycle process, buttotal integrity on the TCERT being used in a specific document and ortransaction. This visual references can be used to verify not only dataand validity of transaction but also references and attachments that canbe verified. With this visual reference also other type of businesstransaction can be achieved like business lifecycles with transactionvoid capabilities and dynamic revocation. All of this with same securityprotocols as Information broker, ENCAB and or independent policies andprocedures.

In another scenario of online signing the client application obtains thehash of the document and is securely sent to the signing server, in thatcase the hash of the file is digitally signed by the server and sentback to the client application. The client application takes the hashand digital signature and implements the signature either in an embeddedformat or opaque signature. Second factor authentication can be used ifnecessary. Since the hash is the only information transmitted there isno obligation for the PCERT or TCERT. Depending on the security policescan be used.

In the case there is a client application that can digitally sign on theuser device, a TCERT or CERT can be used and the transaction record andreferences can be synchronize with the online service. Note that in somecases, data elements are define as data that is being hidden

CONCLUSION

In concluding the detailed description, it should be noted that it wouldbe obvious to those skilled in the art that many variations andmodifications can be made to the preferred embodiment withoutsubstantially departing from the principles of the present invention.Also, such variations and modifications are intended to be includedherein within the scope of the present invention as set forth in theappended claims. Further, in the claims hereafter, the structures,materials, acts and equivalents of all means or step-plus functionelements are intended to include any structure, materials or acts forperforming their cited functions.

It should be emphasized that the above-described embodiments of thepresent invention, particularly any “preferred embodiments” are merelypossible examples of the implementations, merely set forth for a clearunderstanding of the principles of the invention. Any variations andmodifications may be made to the above-described embodiments of theinvention without departing substantially from the spirit of theprinciples of the invention. All such modifications and variations areintended to be included herein within the scope of the disclosure andpresent invention and protected by the following claims.

The present invention has been described in sufficient detail with acertain degree of particularity. The utilities thereof are appreciatedby those skilled in the art. It is understood to those skilled in theart that the present disclosure of embodiments has been made by way ofexamples only and that numerous changes in the arrangement andcombination of parts may be resorted without departing from the spiritand scope of the invention as claimed. Accordingly, the scope of thepresent invention is defined by the appended claims rather than theforgoing description of embodiments.

The invention claimed is:
 1. A computerized system for managing digitalcertificates, said computerized system comprising: one or morecommunicatively coupled computer processors, said one or more computerprocessors forming a certificate authority computer system (CACS)configured to perform the steps of: receiving, at said computer system,a request for an online or offline authorization (OOA) request, said OOArequest containing one or more OOA request data elements, said OOArequest data elements comprising the data for each user related datafield and/or a pointer to the location of said data, said user datainformation being required by the computer system to accomplish(directly or via third parties having proper compliance requirements)the one or more registration validation actions necessary to establishthe bona fides of said user in real time and to perform said userregistration within the system; providing, upon said bona fidessatisfaction, said user with said OOA request, requested ancillary dataelement and one or more OOA requested data elements associated with saidone or more OOA request data elements; receiving, by said CertificateAuthority computer system (CACS), a request for a Transactional DigitalCertificate (TCERT) from a user, said request containing the desired oneor more TCERT user data elements and establishing the existence of avalid OOA data request, performing data validation of one or more ofsaid TCERT request data elements, and/or said OOA data elements, andupon acceptance generating said TCERT digital certificate and TCERTancillary data for said user; transmitting, by said CertificateAuthority computer system, said TCERT digital certificate and anyappropriate TCERT ancillary data to said user.
 2. the computerizedsystem of claim 1 wherein; said TCERT request data elements arecomprised of one or more of the following possible TCERT data elements;actual user data and/or a pointer to the location of said user dataand/or user data field names and/or tokenized values and/or visualreferences to data; and if a portable OOA data request and/or TCERT isdesired, said OOA data request ancillary data and/or said TCERTancillary data optionally contains a Certificate Authority generatedPrivate Key/Public key pair or equivalent security code or keys.
 3. thecomputerized system of claim 2 further comprising; said request for acertificate validation of said TCERT request data elements includesestablishing the validity of each said TCERT data element at the time ofsaid TCERT request.
 4. the computerized system of claim 3 furtherwherein; said TCERT is one of various formats of operation and datastructures, associated but not limited to the X509 standard, referencefiles, references and/or links to actual certified or approved todisplay data, displayable graphical encoded data within aone-dimensional (1D) barcode, two-dimensional (2D) barcode or symbology,visual stenography, sound watermarks or other similar digital mediawhich is attached or implemented in the TCERT or as an attachment to thefile that needs to have the verifiable data.
 5. the computerized systemof claim 4 further comprising; said certificate validation of said TCERTrequest data elements include in addition the real-time multi-factorauthentication (MFA) of said user, wherein said MFA includes at leastone of the following user interactions: telephonic, password, biometric,token (Hardware and/or Software), Password, Pincode, One Time Password,Biometrics (including Face, Finger, Iris, Veins, Voice and others),Machine generated unique codes, Machine Digital Signature, MachineDigital Signature on a secured cryptographic device token and/or Machinegenerated Unique Code on Secure Cryptographic Device token, LDAP, otherauthentication and/or authorization servers/services.
 6. thecomputerized system of claim 2 further comprising; said request for acertificate validation of said TCERT request data elements includeestablishing the validity of each said TCERT data element at the time ofsaid TCERT request; and said certificate validation of said TCERTrequest data elements include in addition the real-time multi-factorauthentication (MFA) of said user, wherein said MFA includes at leastone of the following user interactions: telephonic, password, biometric,token (H/W and/or S/W), Password, Pincode, One Time Password, Biometrics(including Face, Finger, Iris, Veins, Voice and others), Machinegenerated unique codes, Machine Digital Signature, Machine DigitalSignature on a secured cryptographic device token and/or Machinegenerated Unique Code on Secure Cryptographic Device token, LDAP, otherauthentication and/or authorization servers/services.
 7. thecomputerized system of claim 6 further wherein; said TCERT is one ofvarious formats of operation and data structures, associated but notlimited to the X509 standard, reference files, references and/or linksto actual certified or approved to display data, displayable graphicalencoded data within a one-dimensional (1D) barcode, two-dimensional (2D)barcode or symbology, visual stenography, sound watermarks or othersimilar digital media which is attached or implemented in the TCERT oras an attachment to the file that needs to have the verifiable data. 8.A computerized system for managing digital certificates, saidcomputerized system comprising: one or more communicatively coupledcomputer processors, said one or more computer processors forming aCertificate authority computer system (CACS) or equivalent configured toperform the steps of: receiving, at said Certificate Authority computersystem or equivalent, an online or offline authorization (OOA) requestdata element validation from a user desiring validation from saidCertificate Authority of one or more of said OOA request data elements,said request containing one or more OOA request data elements comprisingthe data for each user related data field and/or a pointer to thelocation of said data, said user data information being required by thecomputer system to accomplish (directly or via third parties havingproper compliance requirements) the one or more registration validationactions necessary to establish the bona fides of said user in real timeand to perform said user registration within the system; providing, uponsaid bona fides satisfaction, said user, OOA request ancillary data andone or more of the OOA request data elements associated with said one ormore OOA requested data elements; receiving, by said CertificateAuthority computer system, a request for a Transactional DigitalCertificate (TCERT) from a user, wherein said requested TCERT requestdata elements are comprised of one or more of the following possibleTCERT data elements: a pointer to the location of said user data and/oruser data field names and/or tokenized values and/or visual referencesto data; performing certificate validation of one or more of said TCERTrequest data elements and/or said OOA request data elements, and uponacceptance transmitting to said user the values of the data fieldsincluded in said TCERT request; transmitting, to said CertificateAuthority a digitally signed request including said CertificateAuthority provided data values, said user Public key and digitallysigned by the User; receiving, said data from said user, and generatinga TCERT using said information; and transmitting, by said CertificateAuthority computer system, said TCERT digital certificate and anyappropriate TCERT ancillary data to said user.
 9. the computerizedsystem of claim 8 further comprising; said request for a certificatevalidation of said TCERT request data elements include establishing thevalidity of the data in each said data element at the time of said TCERTemission.
 10. the computerized system of claim 9 further wherein; saidTCERT is one of various formats of operation and data structures,associated but not limited to the X509 standard, reference files,references and/or links to actual certified or approved to display data,displayable graphical encoded data within a one-dimensional (1D)barcode, two-dimensional (2D) barcode or symbology, visual stenography,sound watermarks or other similar digital media which is attached orimplemented in the TCERT or as an attachment to the file that needs tohave the verifiable data.
 11. the computerized system of claim 10further comprising; said certificate validation of said TCERT requestdata elements include in addition the real-time multi-factorauthentication (MFA) of said user, wherein said MFA includes at leastone of the following user interactions: telephonic, password, biometric,token (Hardware and/or Software), Password, Pincode, One Time Password,Biometrics (including Face, Finger, Iris, Veins, Voice and others),Machine generated unique codes, Machine Digital Signature, MachineDigital Signature on a secured cryptographic device token and/or Machinegenerated Unique Code on Secure Cryptographic Device token, LDAP, otherauthentication and/or authorization servers/services.
 12. A method ofmanaging digital certificates, by a computer system, said methodcomprising the steps of: providing one or more communicatively coupledprocessors, said one or more processors forming a certificate authoritycomputer system (CACS) configured to perform the steps of: receiving, atsaid computer system, a request for an online or offline authorization(OOA) request, said OOA request containing one or more OOA request dataelements, said OOA request data elements comprising the data for eachuser related data field and/or a pointer to the location of said data,said user data information being required by the computer system toaccomplish (directly or via third parties having proper compliancerequirements) the one or more registration validation actions necessaryto establish the bona fides of said user in real time and to performsaid user registration within the system; providing, upon said bonafides satisfaction, said user with said OOA request, requested ancillarydata element and one or more OOA requested data elements associated withsaid one or more OOA request data elements; receiving, by saidCertificate Authority computer system, a request for a TransactionalDigital Certificate (TCERT) from a user, said request containing thedesired one or more TCERT user data elements and establishing theexistence of a valid OOA data request, performing data validation of oneor more of said TCERT request data elements, and/or said OOA dataelements, and upon acceptance generating said TCERT digital certificateand TCERT ancillary data for said user; transmitting, by saidCertificate Authority computer system, said TCERT digital certificateand any appropriate TCERT ancillary data to said user.
 13. the method ofclaim 12 wherein; said request for a certificate validation of saidTCERT request data elements includes establishing the validity of eachsaid TCERT data element at the time of said TCERT request.
 14. themethod of claim 13 wherein; said TCERT is one of various formats ofoperation and data structures, associated but not limited to the X509standard, reference files, references and/or links to actual certifiedor approved to display data, displayable graphical encoded data within aone-dimensional (1D) barcode, two-dimensional (2D) barcode or symbology,visual stenography, sound watermarks or other similar digital mediawhich is attached or implemented in the TCERT or as an attachment to thefile that needs to have the verifiable data.
 15. the method of claim 14wherein; said certificate validation of said TCERT request data elementsinclude in addition the real-time multi-factor authentication (MFA) ofsaid user, wherein said MFA includes at least one of the following userinteractions: telephonic, password, biometric, token (Hardware and/orSoftware), Password, Pincode, One Time Password, Biometrics (includingFace, Finger, Iris, Veins, Voice and others), Machine generated uniquecodes, Machine Digital Signature, Machine Digital Signature on a securedcryptographic device token and/or Machine generated Unique Code onSecure Cryptographic Device token, LDAP, other authentication and/orauthorization servers/services.
 16. the method of claim 15 furthercomprising; said request for a certificate validation of said TCERTrequest data elements include establishing the validity of each saidTCERT data element at the time of said TCERT request; and saidcertificate validation of said TCERT request data elements include inaddition the real-time multi-factor authentication (MFA) of said user,wherein said MFA includes at least one of the following userinteractions: telephonic, password, biometric, token (Hardware and/orSoftware), Password, Pincode, One Time Password, Biometrics (includingFace, Finger, Iris, Veins, Voice and others), Machine generated uniquecodes, Machine Digital Signature, Machine Digital Signature on a securedcryptographic device token and/or Machine generated Unique Code onSecure Cryptographic Device token, LDAP, other authentication and/orauthorization servers/services.